Identity management systems are information systems that support the management of identities. In particular, an identity management system establishes the identity of a subject or an object by linking a name (or number) with the subject or object. The identity management system may also describe the identity, for example, by assigning one or more attributes applicable to the particular subject or object to the identity. The identity management system may also modify the identity, such as by linking a new or additional name, or number, with the subject or object and/or change one or more attributes applicable to the particular subject or object. The identity management system can record and/or provide access to logs of activity by the identity.
One of the cornerstones of establishing a secure network environment is making sure that access is restricted to people who have the right to access the network. This access is allowed when the user can authenticate to the identity management system, meaning the user can verify his identity. The authentication may be managed by a public key infrastructure (PKI), such as implemented by a certificate system. For PKI, users and machines may present digital certificates to verify their identity. A digital signature is a mathematical representation of a message, using public key cryptography, which identifies the originator of the message, in a non-forgeable manner. Public key cryptography requires the use of two mathematically related keys—a public key and a private key (collectively referred to as a key pair). The private key is kept private by a single owner, and is not distributed to anyone else. The owner uses his or her private key, in conjunction with cryptographic algorithms, to digitally sign a message. The public key is made public, and can be used by anyone to verify the digital signature on a message. The fact that these two keys are mathematically related ensures that only a single private key can generate a digital signature that is verifiable by the corresponding public key, making the digital signature unforgeable. Public key encryption also allows protection of the confidentiality and integrity of a message or file. Using public key encryption the message or file is encrypted using the public key, which can only be decrypted using the private key. These asymmetric key algorithms allow one key to be made public while retaining the private key in only one location. A digital certificate, commonly referred to as a certificate, is an electronic document used to identify an individual, a server, a company, or another type of entity and to associate that identity with a public key. The digital certificate binds a person's identity to his or her public key, and consequently, to his or her private key, and may be used to verify digital signatures. Digital certificates and digital signatures then provide the foundation for secure transactions over a network, such as the Internet.
Certificate authorities (CAs) validate identities and issue certificates. CAs can be either independent third parties or organizations running their own certificate-issuing server software, such as a certificate system. Before issuing a certificate, a CA must confirm the user's identity with its standard verification procedures. The certificate issued by the CA binds a particular public key to the name of the entity identified by the certificate. In addition to the public key, the certificates include the name of the entity it identifies, an expiration date, and the name of the CA that issued the certificate.
These certificates can be stored on tokens, also referred to as smart cards, smart card tokens, security tokens, hardware tokens, hard token, USB tokens, cryptographic tokens, key fobs, or other hardware security modules (HSMs). The token may be a physical device that an authorized user of computer services is given to ease authentication. Tokens can store a certificate that is used for authenticating the identity of the owner. For example, when a user inserts a smart card into a system, the smart card presents the certificates to the system and identifies the user so the user can be authenticated over the network.
In a conventional system, a token client has a client application, such as an enterprise security client (ESC), which manages the token, and interacts with a token processing system (TPS) of a certificate system. The TPS, which acts as a registration authority (RA) of the CA, coordinates the enrollment process, and acts as a gateway between the token client and the certificate system. The TPS communicates with a token key service (TKS), which maintains master keys for tokens, and may store symmetric keys associated with the token. These keys may be derived from a single master key combined with smart card serial number or card universal identification (CUID) number. The TPS may also communicate with a data recovery manager (DRM), which maintains a database of encrypted private keys for recovery purposes. The DRM can archive the private key for later recovery. Archiving private keys offers protection for users, and for information, if that key is ever lost. When information is encrypted by the public key, the corresponding private key must be available to decrypt the information. If the private key is lost, the data cannot be retrieved. A private key can be lost because of a hardware failure or because the key's owner forgets the password or loses the hardware token in which the key is stored. The TPS also communicates with the CA to issue a certificate in response to the public key information and certificate enrollment request received from the token client. Examples of this conventional system are described in U.S. Patent Publication No. 2008/0022121, U.S. Patent Publication No. 2008/0022088, and U.S. Patent Publication No. 2008/0019526, all filed Jun. 6, 2006 and commonly assigned to the assignee of the present application.
Although most enrollment requests for certificates for tokens include a client-side generated public key, there are times when the token needs a new encryption certificate, or the private key needs to be recovered for the token or generated for a new token when the token has been lost or damaged. In such cases, the TPS sends a request to the TKS on behalf of the token to replace the manufacturer-installed symmetric keys with server-generated keys, derived from the master key, and then submits the public key with the enrollment request to the CA to be issued. Once the CA approves the enrollment request, the TPS sends the certificate and the private key to the client to be stored on the token. These conventional systems may be limited to generating key pairs for token clients, and require a TPS to operate as a gateway between the security client that manages the token of the token client and the components of the certificate system, such as the TKS, DRM, and CA. The conventional certificate systems are not configured to handle server-side key generation for non-token clients.